Elanat is putting a major part of its engineering effort into taking WebForms Core (WFC) toward an increasingly reliable, predictable, and mature state.
The fundamental idea behind WFC is simple to describe, but extremely challenging to implement correctly:
How can a stateless server reliably orchestrate a stateful client?
The WFC model can be represented as:
Stateless Server → Server-Generated Commands → WebFormsJS Executor → HTML DOM
The server generates commands, while WebFormsJS executes those commands inside the browser. Commands can also form sequences, depend on previous commands, read results from the DOM, and use those results as inputs for subsequent operations.
This means that WFC is not simply a server-side rendering mechanism. It is an execution model in which a stateless server orchestrates operations on a stateful and continuously changing client.
That creates a significant set of engineering challenges.
Architectural Challenges
- Race Conditions — multiple requests may execute concurrently, and their responses may return in a different order than they were sent.
- Stale Responses — an older response may arrive after a newer interaction and incorrectly modify the current UI.
- State Synchronization — the server is stateless while the browser maintains UI state. The system must therefore produce correct commands without requiring the server to maintain a permanent representation of the client's DOM state.
- Command Ordering — when multiple commands must execute sequentially, the Executor must preserve their intended order.
- Command Dependency — one command may depend on a DOM state or result produced by a previous command.
- Command Result Dependency — the result produced by one command may become the input of a subsequent command.
- Queue Management — multiple pending operations must be controlled so that commands do not execute in an invalid order.
- Debouncing — preventing unnecessary consecutive requests, such as repeated clicks, and reducing command races during rapid user interaction.
- Command Isolation — preventing commands belonging to one DOM scope from leaking into other DOM scopes.
- Garbage Collection — ensuring that temporary execution data, references, listeners, and other temporary resources do not accumulate unnecessarily.
- Cancellation — determining whether an obsolete command sequence should continue or be cancelled when a newer interaction occurs.
- DOM Drift — the actual DOM may differ from the DOM expected when a command was generated because of previous responses, user interaction, or other client-side changes.
- External DOM Manipulation — dealing with DOM changes made by other JavaScript code, libraries, or applications.
- Multi-Tab State — handling multiple browser tabs belonging to the same application when each tab can have a different client-side DOM state.
Command Execution Challenges
Partial Execution, Failure Recovery, and Rollback — handling situations where only part of a command sequence has executed before a failure, determining the resulting state, and restoring a previous consistent state when necessary. WebForms Core addresses this class of problem through mechanisms such as Transient DOM and rollback-oriented execution.
- Atomicity of Command Sequences — determining what should happen when a sequence contains many operations but one operation in the middle fails.
- Dynamic Targeting — a command target may exist when the command is generated but no longer exist when the command is executed.
- Deleted DOM Elements — commands may target elements that have already been removed by another operation.
- Conditional Execution — execution may depend on conditions evaluated from the current client-side DOM.
- Execution Context — commands may execute within different contexts such as a response, sequence, branch, loop, queue, or other execution scope.
- Transient DOM Management — temporary DOM states must be controlled so that intermediate operations do not unnecessarily expose unstable states to subsequent operations.
- Selector Stability — command targets must be identifiable reliably enough for commands to remain valid as the DOM changes.
- Element Identity — operations such as replacement or tag swapping can change the identity and state of an element.
- Event Handler Lifecycle — DOM changes must not unexpectedly remove required event behavior or create unwanted duplicate handlers.
- Script Execution — received scripts and executable behavior require explicit and predictable execution policies.
- Input State Preservation — server-driven DOM changes should preserve user-entered values in inputs, textareas, and selects where appropriate.
- Focus and Selection Preservation — DOM operations can unintentionally remove focus, caret position, or text selection.
- Scroll Preservation — DOM changes can unexpectedly alter vertical or horizontal scroll positions.
- Form State Preservation — updating part of a server-driven form should not unnecessarily destroy values that the user has entered but has not yet submitted.
- Navigation and Browser History Management — DOM operations and navigation must remain predictable when browser history, back, forward, or navigation-related commands are involved.
Network and Execution Uncertainty
- Network Latency — delayed responses can change the temporal relationship between user interactions, requests, and command execution.
- Network Disconnection — a connection can be interrupted while a request or command sequence is in progress.
- Lost Requests or Responses — a request may be sent while its response never reaches the client.
- Unknown Execution Status — when communication fails, the client may not know whether the server operation was never executed, was executed successfully, or was executed but its response was lost.
- Retry — failed requests may need to be retried without corrupting the current client state.
- Duplicate Execution — retrying an operation can cause the same command or server operation to execute more than once.
- Idempotency — some operations can safely be repeated, while others, such as append operations or resource creation, may not be safely repeatable.
- Connection Recovery — after communication is restored, the client must determine what can safely continue and what must be discarded or regenerated.
- Out-of-Order Responses — parallel Fetch operations can return in an order different from the order in which they were initiated, requiring explicit execution policies.
For failures involving a command sequence, the client also needs mechanisms that can determine what happened and, where appropriate, restore the state that existed before the failed operation. Transient DOM and rollback mechanisms are particularly important for this class of problem.
For network operations, cancellation is also important. When a newer interaction makes previous requests obsolete, WebFormsJS can use request cancellation mechanisms to prevent unnecessary earlier network operations from continuing.
Server–Client Protocol Challenges
- Protocol Versioning — server and client may potentially operate with different versions of the command protocol.
- Capability Detection — the server may need to know whether the client supports a particular command or execution capability.
- Command Validation — the Executor must distinguish valid protocol commands from invalid or unsupported instructions.
- Command Execution Context — the client must maintain sufficient context to execute commands correctly across nested sequences, conditions, loops, and asynchronous operations.
Browser and Client-State Challenges
Event Listener Preservation — dynamically changing the DOM must not unexpectedly destroy required interaction behavior.
- Input State Preservation — user-entered client state must survive appropriate server-driven changes.
- Focus Preservation — users should not unexpectedly lose their current focus during DOM operations.
- Selection and Caret Preservation — text editing state can be lost when elements are replaced or reconstructed.
- Scroll Preservation — visual navigation state can be affected by DOM changes.
- Script and Action Control Management — received scripts and Action Controls, including those delivered through HTML comments, require controlled execution policies.
- External URL Management — externally referenced resources and URLs must be handled according to defined policies.
Many of these problems are not unique to WebForms Core individually. What makes WFC particularly challenging is that they become interconnected because the architecture places a stateless server in the role of orchestrator for a stateful browser.
For example:
User Action
↓
Request
↓
Server Decision
↓
Commands
↓
Network
↓
WebFormsJS
↓
Command 1
↓
Command 2
↓
Command 3
↓
DOM State
A failure or timing change at almost any point can affect the validity of what happens next.
This is why the challenge is not simply creating a command language or a mechanism for modifying the DOM.
The deeper challenge is maintaining predictable causal relationships between user actions, server decisions, network communication, command execution, and the resulting DOM state.
Why This Architecture Is Difficult
The largest technology companies have built highly sophisticated client-side frameworks, but they have generally chosen architectures in which the client owns and manages a substantial portion of application state and rendering.
Making a stateless server the active orchestrator of an already-stateful browser is a fundamentally different direction.
The difficulty is therefore not merely in inventing the idea. The difficult part is building the execution infrastructure required to make that idea reliable enough for real applications.
This is precisely where Elanat is concentrating its engineering effort.
A substantial amount of work has already been implemented in WebForms Core and WebFormsJS to address these challenges. Features such as Queue management, Debouncing, Fetch, conditional execution, command sequencing, Transient DOM, Snapshot and Rollback mechanisms, Cache and Save, and other execution controls are not merely independent features. Many of them exist because of the underlying problems created by server-orchestrated client execution.
However, Elanat does not consider the current implementation to be the final state of the technology.
The continued development of WebFormsJS is focused on improving the execution model, reliability, consistency, recovery, performance, and resilience of WebForms Core.
Tracing and diagnostic capabilities are also being developed and improved so that developers can understand what happened throughout the lifecycle of an interaction:
User Event
↓
Request
↓
Server Decision
↓
Commands
↓
WebFormsJS Execution
↓
DOM Changes
This makes the command pipeline observable and debuggable rather than treating it as a black box.
The objective is not simply to add more commands.
The objective is to make the entire system increasingly predictable, resilient, and efficient.
Ultimately, the central engineering challenge remains:
How can a stateless server reliably orchestrate a stateful client without requiring the server to maintain a permanent representation of the client's UI state?
Elanat is continuing to work on WebFormsJS and WebForms Core to push this architecture as close as possible to an ideal, reliable, and practical implementation.
